Totemomail och Kiteworks EPG: e-postgateway och plattformsbyte

Totemomail var en produktfamilj från schweiziska totemo AG för central e-postkryptering. Efter förvärvet av Kiteworks integrerades koden enligt tillverkaren i Kiteworks-plattformen och vidareutvecklades som Email Protection Gateway, EPG. Namnen betecknar därför inte två helt oberoende produkter, men inte heller samma driftmiljö: en befintlig Totemomail-appliance och ett EPG i Kiteworks Hardened Virtual Appliance har olika gränser för plattform, databas, administration och återställning (Kiteworks: FAQ for totemomail customers, Kiteworks: EPG capability brief).

Funktionellt kvarstår kärnrollen som e-postgateway: den behandlar e-post enligt centrala riktlinjer och använder S/MIME, OpenPGP eller TLS; för mottagare utan lämpliga nycklar finns en WebMail- eller portallösning. Tillverkarens dokumentation beskriver automatisk hantering av nycklar och certifikat samt användning med vanliga e-postklienter utan EPG-specifikt klientinsticksprogram som grundmodell (Kiteworks: Enterprise packaging and EPG features, Microsoft Marketplace: totemomail Encryption Gateway).

För meddelandeadministratörer är produktlinjen framför allt en kedja av förtroendegränser. Gatewayen tar emot ett meddelande via SMTP, klassificerar riktning och identiteter, bestämmer en policy, söker efter nycklar eller en reservkanal, ändrar vid behov MIME-innehållet och överlämnar meddelandet till nästa hopp. Med WebMail tillkommer ett separat tillstånd för webb, konto, nycklar och lagring. Påståendet ”meddelandet är krypterat” är ofullständigt utan angiven metod, skyddad sträcka, nyckelinnehavare och tidpunkt (RFC 5321, RFC 8551, RFC 9580).

Förklaringen följer ett meddelande genom EPG-regler, nyckelval och krypteringsmetoder fram till direkt leverans eller WebMail. Bytet från Totemomail till Kiteworks samt drift, diagnos och återställning behandlas därefter separat.

Totemomail och Kiteworks EPG fungerar som inline-gatewayer i SMTP-sökvägen. Ett meddelande tas emot, tilldelas en identitet och policy, skyddas med en lämplig metod och tillhandahålls sedan via SMTP eller portal. Plattformsbytet ändrar implementering och drift, inte denna grunduppgift.

Arkitekturansats: inline-gateway med central policy

Vid gatewaydrift skickar det interna e-postsystemet utgående meddelanden via SMTP till Totemomail eller EPG. Inkommande meddelanden når gatewayen direkt via MX eller via ett föregående system för e-postsäkerhet. Gatewayen avslutar SMTP-sessionen, behandlar meddelandet och öppnar en ny session för vidarebefordran. En lyckad TCP- eller TLS-handskakning innebär ännu inte att meddelandet har accepterats; ansvarsöverlämningen sker först med det positiva SMTP-svaret vid slutet av DATA-fasen (RFC 5321, avsnitt 4.1.1.4, RFC 3207).

Den offentliga EPG-produktbeskrivningen skiljer mellan flera skyddsvägar. ”Encryption Gateway” omfattar extern gatewaykryptering och -dekryptering. ”Internal Encryption” skyddar meddelanden under transport genom och vid lagring i en molnbaserad e-postplattform. Ytterligare dokumenterade komponenter är Directory Proxy, Application Integration Proxy och en anslutning för RMS respektive Microsoft Information Protection. Vilka av dessa roller som är licensierade och faktiskt aktiverade måste framgå av den egna konfigurationen och avtalet; produktnamnet ensamt styrker dem inte (Kiteworks: Enterprise packaging and licensing).

För Microsoft 365 är transportintegrationen fortfarande ett connectorproblem. Exchange Online måste dirigera meddelanden specifikt till gatewayen och acceptera returtrafik baserat på en tillförlitlig motpartsidentitet. En MX framför en tredjepartsgateway ändrar dessutom vilken käll-IP Exchange Online ser vid spam- och spoofingbedömning. Microsoft dokumenterar connectors och Enhanced Filtering för detta; båda är separata från EPG:s kryptopolicy (Microsoft: Configure mail flow using connectors, Microsoft: Enhanced Filtering for Connectors).

Teknikstack och verifierbara produktgränser

För den historiska Totemomail-plattformen är den kryptografiska kärnan väl offentligt belagd. NIST-CMVP-dokumentationen beskriver Totemo Cryptographic Module, TCM, som ett gemensamt Java-bibliotek i Totemo Security Platform, TSP. Valideringen från 2019 nämner Totemo Appliance OS 2.3, JRE 8 och en mjukvarukryptomodul med AES, RSA, ECDSA, SHA-familjen, HMAC och slumptalsgenerator; posten har numera historisk status och är därför inget belägg för en idag tillåten upphandling eller ett konkret installerat algoritmläge (NIST CMVP Certificate 3500, Totemo TCM Security Policy).

NIST:s säkerhetspolicy avgränsar uttryckligen TCM som en komponent i TSP. Den dokumenterar inte ett fullständigt Totemomail-e-postflöde och inte heller någon generellt giltig implementation av kö, databas eller MTA. Sådana detaljer får därför inte överföras från en främmande Apache James-installation eller en enskild fältobservation till alla Totemomail- eller EPG-versioner. För ett driftokument är exporterad produktkonfiguration, supportmatris, paket- eller tjänsteinventering och tillverkarhandbok för den faktiskt installerade generationen avgörande.

Med EPG flyttas gränsen till Kiteworks Hardened Virtual Appliance. Migrations-FAQ:n beskriver att operativsystem, webbserver och databas ingår i appliance-lösningen och att kundadministratörer inte har direkt åtkomst till operativsystem eller databas. Uppdateringar installeras som en testad appliance-enhet. Detta minskar kundens drift av enskilda komponenter, men gör appliance-processerna för backup, kluster, uppdatering och support till den primära kontrollpunkten (Kiteworks: FAQ for totemomail customers).

Jämförelsen följer tillverkarens migrations-FAQ och de publicerade EPG-funktionsbeskrivningarna. Där Totemomail-detaljer är installationsberoende lämnas detta medvetet som en kontrollpunkt i stället för som en påhittad produktegenskap (Kiteworks: totemomail-to-EPG migration FAQ, Kiteworks: Top reasons for EPG).

SMTP-e-postflöde och looprisk

En gatewayväg behöver ett tydligt ansvar för varje riktning. Utgående får e-postsystemet inte leverera valfritt direkt eller via EPG om endast gatewayvägen utför den föreskrivna policyn. Inkommande måste det vara fastställt om MX, föregående filter eller EPG autentiserar den ursprungliga avsändaren och vilket hopp som når den interna e-postservern. Flera dubbelriktade connectors utan tydlig mottagar- och domänauktoritet kan få meddelanden att cirkulera mellan system (RFC 5321: Trace information and loop detection, Microsoft: Mail flow using a third-party cloud service).

För varje produktionsrutt bör administratörer dokumentera följande värden tillsammans:

• källnät eller certifikatbaserad peer-identitet och förväntat EHLO-namn;
• lokal mottagningsadress, port, STARTTLS- och klientcertifikatkrav;
• ansvar för auktoritativ domän, relä eller split domain;
• policyriktning, användar- och mottagarklassificering;
• nästa hopp, DNS- eller smarthostupplösning och TLS-krav;
• beteende när policy-, nyckel-, katalog- eller portalkomponent inte kan nås;
• maximalt antal hopp, köålder samt ansvar för återförsök och studsmeddelanden.

SMTP-standarden kräver att Received-rader läggs till vid varje vidarebefordran och beskriver loopdetektering med hjälp av spårningsvägen. För diagnos och revision måste gatewayens händelse-ID kunna korreleras med Internet Message-ID, envelope, tidsfönster och efterföljande spårning. En synlig ämnesrad är ingen stabil identifierare och kan ändras av policy eller webbleverans (RFC 5321, avsnitt 4.4, RFC 5322: Message-ID).

Efter SMTP-mottagningen beslutar policy engine, baserat på avsändare, mottagare, katalog och tillgängliga nycklar, vilken skyddsväg som är tillåten och möjlig.

Policy engine och identitetsbeslut

Kiteworks beskriver EPG som ett automatiskt, policystyrt beslutslager. Beroende på licensierad funktionsomfattning kan regler baseras på domäner, användare, platser, innehållsegenskaper eller Microsoft Information Protection-etiketter. Automatisering eliminerar dock inte behovet av att lita på indata: en avsändarheader, en ämnesutlösare eller en etikett som satts utifrån får inte otestat ha samma effekt som en autentiserad intern identitet (Kiteworks: EPG capability brief, Kiteworks: totemo and Kiteworks better together).

En robust regelmodell skiljer mellan fyra frågor:

1. Riktning: internt till externt, externt till internt, internt till internt eller applikation till externt.
2. Identitet: SMTP-envelope, synlig From:, autentiserad session, connector, katalogobjekt och tenant är inte samma sak.
3. Åtgärd: signera, kryptera, omkryptera, portalleverans, vidarebefordra oförändrat, tillfälligt avvisa eller studsa permanent.
4. Felväg: saknad nyckel, ogiltig kedja, oåtkomlig katalog, policyfel och oåtkomligt nästa hopp behöver separata resultat.

Före ändringar bör en liten testmatris köras med exakt en avsändare och mottagare per identitetsklass. För varje rad dokumenteras förväntad regel, metod, synlig avsändare, mottagarkanal, loggmarkör och felbeteende. Först när dessa resultat är reproducerbara är policyn inte bara konfigurerad utan även styrkt.

Skyddsmetoder och omkryptering

S/MIME använder CMS och X.509-certifikat. Gatewayen behöver en privat nyckel för signering eller dekryptering och ett lämpligt offentligt certifikat för mottagarkryptering. Certifikatkedja, namn eller e-postadress, Key Usage, giltighet och spärrinformation ingår i kontrollen (RFC 5652, RFC 5280, RFC 6960).

OpenPGP använder en fristående modell för nycklar, signaturer och paket. Fingeravtryck, User ID, kapaciteter, utgång och återkallelse måste inventeras oberoende av X.509. En automatiskt inlärd offentlig nyckel är bara så tillförlitlig som den dokumenterade inlärnings- och bekräftelsevägen. Produktdokumentationen nämner S/MIME och OpenPGP sida vid sida, men gör dem inte till utbytbara trustmodeller (Kiteworks: Enterprise EPG feature matrix).

SMTP-TLS skyddar en enskild transportförbindelse. Vid opportunistisk STARTTLS kan leveransen utan ytterligare policy falla tillbaka till klartext. En bindande peer-identitet kan, beroende på miljö, fastställas genom certifikatkontroll, DANE eller MTA-STS; detta skyddar ändå inte meddelandet från de deltagande MTA:erna (RFC 3207, RFC 7672, RFC 8461).

Vid omkryptering dekrypterar gatewayen en inkommande metod och skapar en ny för nästa avsnitt. Det möjliggör innehållskontroll eller protokollbyte, men skapar ett klartextögonblick inom gatewaygränsen. EPG-funktionskatalogen beskriver uttryckligen scenarier där internt skyddade meddelanden kort dekrypteras vid gatewayen för att kontrolleras eller omvandlas till mottagarens standard (Kiteworks: Internal Encryption and Encryption Gateway). DLP, antivirus, tillfälliga filer, minnesavbildningar, felsökningsloggar och administratörsåtkomst ingår då i kryptogränsen.

Om en direkt användbar mottagarnyckel saknas flyttar portalleveransen klartextåtkomsten till en webbapplikation. Därmed blir webbidentitet, session och lagrat meddelande en del av driftmodellen.

WebMail och portalleverans

Den officiella migrations-FAQ:n bekräftar att EPG tillhandahåller en funktion som motsvarar Totemomail WebMail för mottagare utan lämplig e-postkryptering. Offentliga operatörsanvisningar för Totemomail visar det typiska användarflödet: avisering, första lösenord eller registreringslänk, lösenordsbyte, inloggning på portalen och val mellan WebMail, S/MIME eller OpenPGP (Kiteworks: Migration FAQ, fråga 7, L-Bank: Säker e-postkommunikation).

Portalleverans är en separat lagrings- och identitetsväg. Aviseringsmeddelandet innehåller inte nödvändigtvis det konfidentiella meddelandet; innehållet kan finnas på portalen eller i ett lösenordsskyddat kuvert. För administratörer är därför minst värdnamn, TLS-certifikat, kontostatus, lösenords- och återställningsförfarande, bevarandetid, meddelandenycklar, leveranshistorik och raderingsprocess relevanta. Den valda varianten måste följa den egna policyn; externa operatörsanvisningar belägger möjliga Totemomail-funktioner, men inga globala standardinställningar.

En portalhälsokontroll får inte stanna vid HTTP 200. Det syntetiska testet måste omfatta registrering eller befintligt testkonto, inloggning, öppning av ett på förhand känt meddelande, hämtning av en bilaga, svar och utloggning. Efter en återställning är det särskilt viktigt att kontrollera om äldre portalmaterial fortfarande kan läsas med sina historiska nycklar.

Katalog och nycklar med licensräkning

Kiteworks dokumenterar LDAP/AD-integration, roller och centrala policyer på plattformsnivå. För en gateway kan katalogen klassificera avsändare och mottagare, tillhandahålla gruppvillkor och koppla identiteter till certifikat eller nycklar. Så snart en regel beror på en katalogfråga ingår LDAP-endpoint, Search Base, filter, bindkonto, TLS-förtroende, timeout, cache och failover i meddelandevägen (Kiteworks: security and integration overview, RFC 4511, RFC 4513).

Nyckelbeståndet är ingen biprodukt av användarimporten. Privata användar- och domännycklar, offentliga mottagarnycklar, CA- och intermediate-certifikat, förtroendestatus, spärrinformation, Keyserver- respektive MPKI-anslutningar och koppling till historiska meddelanden ska inventeras. En rensning i katalogen får aldrig utan kontroll ta bort en privat nyckel som behövs för gamla meddelanden.

Ett publicerat Kiteworks-dokument om paketering definierade EPG-platser så att en intern användare förbrukar en plats vid sändning eller mottagning av ett krypterat meddelande eller vid sändning av ett signerat meddelande; interna användare som passerade okrypterat och osignerat behandlades där annorlunda. Dokumentet är en daterad avtalsbeskrivning, ingen tidlös licensgaranti (Kiteworks: Enterprise 8.0 licensing and packaging). För drift måste därför tre värden hållas åtskilda: tekniskt kända identiteter, faktiskt kryptografiskt aktiva identiteter och den avtalsmässigt licensierade metriken för den egna beställningen.

Vid bytet till EPG måste därför inte bara SMTP-rutter utan även regler, identiteter, nycklar, portaltillstånd och bevis övertas eller medvetet byggas upp på nytt.

Migrering från Totemomail till EPG

Kiteworks beskriver inte migreringen som en in-place-omdöpning. En automatiserad överföring kopierar information från den befintliga Totemomail-databasen till EPG-databasen. Den gamla externa databasen ska avvecklas efter att Totemomail-systemet har tagits ur drift, eftersom den därefter inte längre är synkroniserad. EPG innehåller själv databas, operativsystem och webbtjänster i Hardened Virtual Appliance (Kiteworks: Migration FAQ).

En fullständig migreringsomfattning består minst av:

• domäner, rutter, relä- och connectoridentiteter samt TLS-policyer;
• aktiva regler, prioriteringar, utlösare, undantag och felvägar;
• S/MIME-, OpenPGP-, domän-, TLS- och CA-nycklar inklusive historik;
• WebMail-konton, portalmeddelanden, bevarande, mallar och offentligt namn;
• katalog-, SSO-, SIEM-, Syslog-, DLP-, arkiv- och applikationsintegrationer;
• roller, administratörer samt åtkomst för revision och support;
• licensmetrik, aktivt användarbestånd och avtalsgränser;
• backup, återställning, HA, DNS, övervakning och runbooks.

Acceptanstestet måste utöver nya e-postmeddelanden även kontrollera historiska data. För varje gammal krypteringsmetod öppnas respektive dekrypteras ett meddelande som skapats före migreringen. För varje riktning skickas ett nytt testmeddelande med och utan befintlig mottagarnyckel. Dessutom kontrolleras negativa fall som ogiltigt certifikat, oåtkomligt nästa hopp och otillgänglig katalog. Först därefter kan den gamla gatewayen tas bort från DNS, connectors, allowlistor och övervakning.

Hög tillgänglighet med backup och återställning

EPG-migrations-FAQ:n nämner integrerad klustring, backup/återställning, katastrofåterställning, hög tillgänglighet och distribution som egenskaper hos Hardened Virtual Appliance. Den säger dock inte att varje enskild EPG-funktion automatiskt får samma RPO och RTO. E-postkö, databas, nycklar, portalinnehåll, revisionslogg, konfiguration och extern objekt- eller fillagring måste tilldelas separat beroende på arkitektur (Kiteworks: Migration FAQ – Hardened Virtual Appliance).

För äldre Totemomail är backupförfarandet beroende av version och installation. EPG-uppgiften om integrerad backup får inte retroaktivt överföras till en gammal extern databas eller en separat WebMail-lagring. Tillverkarens supportväg, den installerade dokumentationen och ett isolerat återställningstest är här primärkällorna.

Övervakning och säkerhetsdrift

Kiteworks bekräftar för EPG export till ett eller flera Syslog-mål samt Splunk-integration. Plattformsdokumentationen beskriver normaliserade loggar och metadata för e-post och andra kommunikationskanaler. För meddelandeadministratörer är den sakliga korrelationen avgörande: plattformsrevision, SMTP-händelse, policybeslut, nyckeloperation, portalåtkomst och efterföljande message trace måste sammanföras via tid, identitet och meddelandeidentifierare (Kiteworks: Migration FAQ – syslog, Kiteworks: EPG logging and audit).

En administratörsdashboard bör minst visa mottagningar och avvisningar, köålder per nästa hopp, policyfel, antal och typ av kryptoåtgärder, saknade eller ogiltiga nycklar, certifikatutgång, LDAP-latens, fel vid portalinloggning, disk- och databastillstånd, klusterreplikering, backupålder och Syslog-förlust. En tom kö är bara ett positivt fynd om meddelanden samtidigt tas emot och framgångsrikt överlämnas till nästa hopp.

Syslog via UDP erbjuder ingen garanterad leverans. För skyddsvärda revisionsdata måste TLS-transport, buffring, målautentisering, korrekt tid och ett avbrottslarm planeras (RFC 5424, RFC 5425). Loggar kan innehålla avsändare, mottagare, ämnesrad, certifikatinformation eller portalaktiviteter; dataminimering och åtkomstskydd ingår därför i loggningspolicyn.

Historiska säkerhetsmeddelanden visar att även webbgränssnittet är en del av angreppsytan. NVD-poster dokumenterar bland annat tidigare CSRF-, objektåtkomst- och XSS-sårbarheter i Totemomail-webbkomponenter. Detta innebär inget uttalande om en godtycklig, okontrollerad patchnivå, men däremot den bestående skyldigheten att inkludera tillverkaranvisningar, exponering, supportstatus och webbportaltester i patchhanteringen (NVD: CVE-2018-6563, NVD: CVE-2020-7918, NVD: CVE-2024-28063).

Diagnosen följer ett testmeddelande från mottagning via policy- och nyckelbeslut fram till SMTP-utgång eller portalåtkomst.

Diagnosverktyg

Diagnosen börjar vid den publicerade e-postvägen och följer sedan EPG-händelserna fram till leverans eller WebMail. Plattformsmigrering och licensstatus kontrolleras först när det berörda bearbetningssteget har fastställts.

DNS och offentliga e-postvägar

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 och dig visar offentlig MX, gatewayadress och i förekommande fall DANE-TLSA. Intern och extern resolvervy ska kontrolleras separat. För Microsoft 365 beskriver MX endast det första internethoppet; connectors och transportregler bestämmer den fortsatta vägen.

TCP-, SMTP- och TLS-åtkomlighet

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 och nc belägger endast TCP-vägen. Windows-curl.exe begär SMTP-STARTTLS; openssl s_client visar funktioner, handskakning, SNI och certifikatkedja. Först en fullständig SMTP-transaktion med positivt DATA-svar belägger mottagning.

Auktoriserat SMTP-testmeddelande

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 och swaks skickar här ett kontrollerat testmeddelande. Avsändare, mottagare och mål måste uttryckligen vara auktoriserade för detta. SMTP-slutsvar, gateway-ID, utlöst policy, använd nyckel eller portalväg, nästa hopp och faktisk ankomst ska loggas. Ett 250 på RCPT TO innebär ännu inte att meddelandeinnehållet har accepterats.

WebMail- eller portalväg

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 och openssl s_client kontrollerar HTTP- och TLS-gränssnittet. En lyckad statuskod styrker varken inloggning eller nyckelåtkomst. Ett syntetiskt webbläsartest måste omfatta inloggning, öppning av ett känt meddelande, bilaga och svar.

Paketväg vid rätt mätpunkt

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 och tcpdump ser endast trafik vid den valda mätpunkten. En administratörsklient observerar inte automatiskt vägen mellan Exchange Online, Load Balancer och EPG. För analys lämpar sig en auktoriserad värd, port mirror eller cloud flow logs; SMTP före STARTTLS och webbmetadata ska lagras med lämpligt skydd.

Teknisk historia

Totemo grundades 2001 i Schweiz och utvecklade lösningar för e-postkryptering, Managed File Transfer och mobil kommunikation. NIST-valideringarna från 2012 och 2019 dokumenterar utvecklingen av den Java-baserade Totemo Cryptographic Module och Totemo Security Platform på egna appliance-operativsystem (Entrust Partner Directory: Totemo, NIST: TCM Security Policy 2012, NIST CMVP Certificate 3500).

Kiteworks förvärvade totemo i januari 2022. Tillverkarens dokumentation beskriver integrationen av Totemomail-koden i Kiteworks-plattformen och namnändringen till Email Protection Gateway. EPG kombinerade de befintliga funktionerna för e-postkryptering med Hardened Virtual Appliance, gemensamma roller, normaliserade loggar och ytterligare Kiteworks-kommunikationskanaler (Kiteworks: acquisition and EPG integration, Kiteworks: Migration FAQ, Kiteworks: January 2022 acquisition).

Övergången är tekniskt relevant: den gamla produkten kunde drivas med en extern databas; EPG övertar dess data i en integrerad databas och flyttar underhållet av operativsystem och databas inom appliance-gränsen. Runbooks, övervakning och återställning får därför inte bara ersätta produktbegrepp, utan måste tilldela kontrollpunkter samt lagrade data och konfigurationer på nytt.

Källor

• Kiteworks – FAQ for totemomail Customers Updating to EPG
• Kiteworks – Top 6 Reasons to Add Email Protection Gateway
• Kiteworks – Enterprise 8.0 Licensing and Packaging
• Microsoft Marketplace – totemomail Encryption Gateway
• IETF RFC 5321 – Simple Mail Transfer Protocol
• IETF RFC 8551 – S/MIME 4.0
• IETF RFC 9580 – OpenPGP
• IETF RFC 3207 – SMTP STARTTLS
• Microsoft – Configure mail flow using connectors
• Microsoft – Enhanced Filtering for Connectors
• NIST CMVP – Certificate 3500, Totemo Cryptographic Module
• NIST – Totemo Cryptographic Module Security Policy 2019
• Microsoft – Manage mail flow using a third-party cloud service
• RFC 5322: Message-ID
• Kiteworks – Top 5 Reasons totemo and Kiteworks Are Better Together
• IETF RFC 5652 – Cryptographic Message Syntax
• IETF RFC 5280 – X.509 PKI Certificate and CRL Profile
• IETF RFC 6960 – Online Certificate Status Protocol
• IETF RFC 7672 – SMTP Security via DANE
• IETF RFC 8461 – MTA Strict Transport Security
• L-Bank – Säker e-postkommunikation med Totemomail
• Kiteworks – Security and Integration Overview
• IETF RFC 4511 – LDAP Protocol
• IETF RFC 4513 – LDAP Authentication Methods and Security Mechanisms
• IETF RFC 5424 – Syslog Protocol
• IETF RFC 5425 – TLS Transport Mapping for Syslog
• NVD – CVE-2018-6563
• NVD – CVE-2020-7918
• NVD – CVE-2024-28063
• Microsoft Learn – Resolve-DnsName
• ISC BIND 9 – dig manpage
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc manpage
• curl – command line manpage
• OpenSSL – s_client
• swaks – SMTP test tool
• Microsoft Learn – Invoke-WebRequest
• Microsoft Learn – pktmon
• tcpdump – manual page
• Entrust Partner Directory – Totemo
• NIST – Totemo Cryptographic Module Security Policy 2012
• Kiteworks – The Deal: On the Hunt