Totemomail e Kiteworks EPG: gateway e-mail e cambio di piattaforma

Totemomail era una famiglia di prodotti della svizzera totemo AG per la crittografia centralizzata delle e-mail. Dopo l’acquisizione da parte di Kiteworks, secondo il produttore il codice è stato integrato nella piattaforma Kiteworks e proseguito come Email Protection Gateway, EPG. I nomi non designano quindi due prodotti del tutto indipendenti, ma nemmeno lo stesso ambiente operativo: un’appliance Totemomail esistente e un EPG all’interno della Kiteworks Hardened Virtual Appliance presentano limiti diversi per piattaforma, database, amministrazione e ripristino (Kiteworks: FAQ for totemomail customers, Kiteworks: EPG capability brief).

Dal punto di vista funzionale, il ruolo centrale rimane quello di un gateway e-mail: elabora le e-mail secondo direttive centrali e utilizza S/MIME, OpenPGP o TLS; per i destinatari senza chiavi adeguate è disponibile una soluzione WebMail o portale. La documentazione del produttore descrive la gestione automatica di chiavi e certificati, nonché l’utilizzo con normali client di posta senza plug-in client specifico per EPG come modello di base (Kiteworks: Enterprise packaging and EPG features, Microsoft Marketplace: totemomail Encryption Gateway).

Per gli amministratori di messaggistica, la linea di prodotti è soprattutto una catena di confini di fiducia. Il gateway accetta un messaggio tramite SMTP, classifica direzione e identità, determina una policy, cerca chiavi o un canale alternativo, eventualmente modifica il contenuto MIME e consegna il messaggio al successivo hop. Con WebMail si aggiunge uno stato proprio di web, account, chiavi e archiviazione. L’affermazione «il messaggio è crittografato» è incompleta senza indicare metodo, tratto protetto, titolare della chiave e momento (RFC 5321, RFC 8551, RFC 9580).

La spiegazione segue un messaggio attraverso le regole EPG, la selezione delle chiavi e il metodo di crittografia fino al recapito diretto o a WebMail. Il passaggio da Totemomail a Kiteworks, l’esercizio, la diagnosi e il ripristino vengono poi trattati separatamente.

Totemomail e Kiteworks EPG operano come gateway inline nel percorso SMTP. Un messaggio viene accettato, assegnato a un’identità e a una policy, protetto con una procedura appropriata e quindi reso disponibile tramite SMTP o portale. Il cambio di piattaforma modifica implementazione e gestione, non questo compito fondamentale.

Approccio architetturale: gateway inline con policy centrale

Nel funzionamento come gateway, il sistema di posta interno invia messaggi in uscita tramite SMTP a Totemomail o EPG. I messaggi in entrata raggiungono il gateway direttamente tramite MX o attraverso un sistema di sicurezza e-mail a monte. Il gateway termina la sessione SMTP, elabora il messaggio e apre una nuova sessione per l’inoltro. Un handshake TCP o TLS riuscito non costituisce ancora accettazione del messaggio; il trasferimento di responsabilità avviene solo con la risposta SMTP positiva alla fine della fase DATA (RFC 5321, sezione 4.1.1.4, RFC 3207).

La descrizione pubblica del prodotto EPG distingue diversi percorsi di protezione. «Encryption Gateway» copre la crittografia e la decrittografia esterne del gateway. «Internal Encryption» protegge i messaggi durante il transito e l’archiviazione in una piattaforma e-mail cloud. Ulteriori componenti documentati sono Directory Proxy, Application Integration Proxy e un connettore per RMS o Microsoft Information Protection. Quali di questi ruoli siano concessi in licenza e realmente attivati deve risultare dalla configurazione e dal contratto propri; il solo nome del prodotto non lo dimostra (Kiteworks: Enterprise packaging and licensing).

Per Microsoft 365, l’integrazione del trasporto rimane una questione di connettori. Exchange Online deve instradare i messaggi in modo mirato verso il gateway e accettare il traffico di ritorno sulla base di un’identità affidabile della controparte. Un MX davanti a un gateway di terze parti modifica inoltre l’IP sorgente che Exchange Online vede per la valutazione di spam e spoofing. Microsoft documenta a tale scopo connettori e Enhanced Filtering; entrambi sono separati dalla cryptopolicy EPG (Microsoft: Configure mail flow using connectors, Microsoft: Enhanced Filtering for Connectors).

Stack tecnologico e limiti di prodotto verificabili

Per la piattaforma storica Totemomail, il nucleo crittografico è ben documentato pubblicamente. La documentazione NIST-CMVP descrive il Totemo Cryptographic Module, TCM, come libreria Java condivisa della Totemo Security Platform, TSP. La convalida del 2019 cita Totemo Appliance OS 2.3, JRE 8 e un modulo crittografico software con AES, RSA, ECDSA, famiglia SHA, HMAC e generatore di numeri casuali; la voce ha ora status storico e pertanto non dimostra una fornitura oggi ammissibile né una modalità algoritmica concreta installata (NIST CMVP Certificate 3500, Totemo TCM Security Policy).

La policy di sicurezza NIST delimita esplicitamente TCM quale componente della TSP. Non documenta un flusso di posta Totemomail completo né un’implementazione generale di coda, database o MTA. Tali dettagli non devono quindi essere trasferiti da un’installazione Apache James estranea o da una singola rilevazione sul campo a tutte le versioni di Totemomail o EPG. Per un documento operativo sono determinanti la configurazione esportata del prodotto, la matrice di supporto, l’inventario di pacchetti o servizi e il manuale del produttore della generazione effettivamente installata.

Con EPG, il confine si sposta alla Kiteworks Hardened Virtual Appliance. Le FAQ sulla migrazione descrivono che sistema operativo, web server e database sono contenuti nell’appliance e che gli amministratori dei clienti non ottengono accesso diretto al sistema operativo o al database. Gli aggiornamenti vengono installati come unità appliance testata. Ciò riduce la gestione dei componenti da parte del cliente, ma rende procedure di backup, cluster, aggiornamento e supporto dell’appliance la superficie di controllo primaria (Kiteworks: FAQ for totemomail customers).

Il confronto si basa sulle FAQ di migrazione del produttore e sulle descrizioni pubblicate delle funzioni EPG. Laddove i dettagli di Totemomail dipendono dall’installazione, ciò rimane volutamente un punto da verificare anziché essere presentato come caratteristica di prodotto inventata (Kiteworks: totemomail-to-EPG migration FAQ, Kiteworks: Top reasons for EPG).

Mail flow SMTP e rischio di loop

Un percorso gateway richiede una responsabilità univoca per ogni direzione. In uscita, il sistema di posta non deve poter recapitare alternativamente direttamente o tramite EPG se solo il percorso gateway esegue la policy prescritta. In entrata, deve essere stabilito se MX, filtri a monte o EPG autenticano il mittente originario e quale hop raggiunge il server di posta interno. Più connettori bidirezionali senza una chiara autorità su destinatari e domini possono far circolare i messaggi tra i sistemi (RFC 5321: Trace information and loop detection, Microsoft: Mail flow using a third-party cloud service).

Per ogni route produttiva, gli amministratori dovrebbero documentare congiuntamente i seguenti valori:

• rete sorgente o identità del peer basata su certificato e nome EHLO atteso;
• indirizzo di accettazione locale, porta, requisiti STARTTLS e certificato client;
• responsabilità autorevole, relay o split-domain;
• direzione della policy, classificazione di utenti e destinatari;
• hop successivo, risoluzione DNS o smarthost e requisito TLS;
• comportamento in caso di componente di policy, chiave, directory o portale non raggiungibile;
• numero massimo di hop, età della coda, responsabilità per retry e bounce.

Lo standard SMTP richiede l’aggiunta di righe Received a ogni inoltro e descrive il rilevamento dei loop in base al percorso di traccia. Per diagnosi e audit, l’ID evento del gateway deve essere correlabile con Internet Message-ID, envelope, intervallo temporale e traccia a valle. Un oggetto visibile non è un identificatore stabile e può essere modificato dalla policy o dal recapito web (RFC 5321, sezione 4.4, RFC 5322: Message-ID).

Dopo l’accettazione SMTP, il motore di policy decide, in base a mittente, destinatario, directory e chiavi disponibili, quale percorso di protezione sia consentito e possibile.

Motore di policy e decisione sull’identità

Kiteworks descrive EPG come livello decisionale automatico e guidato da policy. A seconda dell’ambito di funzioni concesso in licenza, le regole possono basarsi su domini, utenti, luoghi, caratteristiche del contenuto o etichette Microsoft Information Protection. Tuttavia, l’automazione non elimina la necessità di fidarsi degli input: un’intestazione del mittente, un trigger nell’oggetto o un’etichetta impostata dall’esterno non devono avere senza verifica lo stesso effetto di un’identità interna autenticata (Kiteworks: EPG capability brief, Kiteworks: totemo and Kiteworks better together).

Un modello di regole affidabile separa quattro questioni:

1. Direzione: interno verso esterno, esterno verso interno, interno verso interno o applicazione verso esterno.
2. Identità: envelope SMTP, From: visibile, sessione autenticata, connettore, oggetto directory e tenant non sono la stessa cosa.
3. Azione: firmare, crittografare, ricrittografare, recapito tramite portale, inoltrare senza modifiche, rifiutare temporaneamente o generare un bounce permanente.
4. Percorso di errore: chiave mancante, catena non valida, directory non raggiungibile, errore di policy e hop successivo non raggiungibile richiedono risultati distinti.

Prima delle modifiche, dovrebbe essere eseguita una piccola matrice di test con esattamente un mittente e un destinatario per classe di identità. Per ogni riga si registrano regola attesa, procedura, mittente visibile, canale destinatario, indicatore di log e comportamento in caso di errore. Solo quando questi risultati sono riproducibili, la policy non è soltanto configurata, ma dimostrata.

Metodi di protezione e ricrittografia

S/MIME utilizza CMS e certificati X.509. Per firma o decrittografia, il gateway necessita di una chiave privata e, per la crittografia del destinatario, di un certificato pubblico idoneo. Percorso del certificato, nome o indirizzo e-mail, Key Usage, validità e informazioni di revoca fanno parte della verifica (RFC 5652, RFC 5280, RFC 6960).

OpenPGP utilizza un modello autonomo di chiavi, firme e pacchetti. Fingerprint, User ID, capacità, scadenza e revoca devono essere inventariati indipendentemente da X.509. Una chiave pubblica appresa automaticamente è affidabile solo quanto il percorso documentato di apprendimento e conferma. La documentazione del prodotto cita S/MIME e OpenPGP uno accanto all’altro, ma non li rende modelli di fiducia intercambiabili (Kiteworks: Enterprise EPG feature matrix).

SMTP-TLS protegge una singola connessione di trasporto. Con STARTTLS opportunistico, il recapito può ripiegare sul testo in chiaro senza una policy aggiuntiva. A seconda dell’ambiente, un’identità peer vincolante può essere definita tramite verifica del certificato, DANE o MTA-STS; ciò non protegge comunque il messaggio dagli MTA coinvolti (RFC 3207, RFC 7672, RFC 8461).

Nella ricrittografia, il gateway decrittografa un metodo in entrata e ne crea uno nuovo per il tratto successivo. Ciò consente l’ispezione del contenuto o il cambio di protocollo, ma crea un momento in chiaro entro il confine del gateway. Il catalogo delle funzioni EPG descrive esplicitamente scenari in cui messaggi protetti internamente vengono brevemente decrittografati al gateway per ispezionarli o convertirli nello standard del destinatario (Kiteworks: Internal Encryption and Encryption Gateway). DLP, antivirus, file temporanei, dump di memoria, log di debug e accesso amministrativo fanno allora parte del confine crittografico.

Se manca una chiave destinatario direttamente utilizzabile, il recapito tramite portale sposta l’accesso al testo in chiaro in un’applicazione web. Identità web, sessione e messaggio memorizzato diventano così parte del modello operativo.

WebMail e recapito tramite portale

Le FAQ ufficiali sulla migrazione confermano che EPG fornisce una funzione corrispondente a Totemomail WebMail per destinatari senza crittografia e-mail adeguata. Le istruzioni pubbliche per operatori di Totemomail mostrano il tipico flusso utente: notifica, password iniziale o link di registrazione, cambio password, accesso al portale e scelta tra WebMail, S/MIME o OpenPGP (Kiteworks: Migration FAQ, domanda 7, L-Bank: Sichere E-Mail-Kommunikation).

Il recapito tramite portale è un percorso distinto di archiviazione e identità. L’e-mail di notifica non contiene necessariamente il messaggio riservato; il contenuto può trovarsi sul portale o in un envelope protetto da password. Per gli amministratori sono quindi rilevanti almeno hostname, certificato TLS, stato dell’account, procedure di password e reset, periodo di conservazione, chiavi del messaggio, cronologia di recapito e processo di cancellazione. La variante scelta deve derivare dalla policy propria; le istruzioni di operatori esterni dimostrano possibili funzioni Totemomail, ma non impostazioni predefinite globali.

Un controllo di integrità del portale non deve fermarsi a HTTP 200. Il test sintetico deve includere registrazione o account di test esistente, login, apertura di un messaggio noto in anticipo, download di un allegato, risposta e logout. Dopo un ripristino, occorre verificare in particolare che i contenuti più vecchi del portale continuino a essere leggibili con le rispettive chiavi storiche.

Directory e chiavi con conteggio delle licenze

Kiteworks documenta l’integrazione LDAP/AD, i ruoli e le policy centrali a livello di piattaforma. Per un gateway, la directory può classificare mittenti e destinatari, fornire condizioni di gruppo e associare identità a certificati o chiavi. Non appena una regola dipende da una query di directory, LDAP-endpoint, Search Base, filtro, account Bind, fiducia TLS, timeout, cache e failover fanno parte del percorso del messaggio (Kiteworks: security and integration overview, RFC 4511, RFC 4513).

L’archivio delle chiavi non è un sottoprodotto dell’importazione utenti. Devono essere inventariate chiavi private di utenti e domini, chiavi pubbliche dei destinatari, certificati CA e intermedi, stato di fiducia, informazioni di revoca, connessioni Keyserver o MPKI e associazione a messaggi storici. Una pulizia della directory non deve mai rimuovere senza verifica una chiave privata necessaria per vecchi messaggi.

Un documento di packaging Kiteworks pubblicato definiva le postazioni EPG in modo che un utente interno consumasse una postazione inviando o ricevendo un messaggio crittografato oppure inviando un messaggio firmato; gli utenti interni che transitavano senza crittografia e senza firma venivano trattati diversamente. Il documento è una descrizione contrattuale datata, non una garanzia di licenza senza tempo (Kiteworks: Enterprise 8.0 licensing and packaging). Per l’esercizio, devono pertanto essere gestiti separatamente tre valori: identità tecnicamente note, identità realmente attive dal punto di vista crittografico e metrica contrattualmente concessa in licenza del proprio ordine.

Nel passaggio a EPG, quindi, non devono essere trasferiti o ricostruiti consapevolmente solo i percorsi SMTP, ma anche regole, identità, chiavi, stati del portale e prove.

Migrazione da Totemomail a EPG

Kiteworks non descrive la migrazione come una ridenominazione in-place. Un trasferimento automatizzato copia informazioni dal database Totemomail esistente al database EPG. Il vecchio database esterno deve essere dismesso dopo la disattivazione del sistema Totemomail, poiché successivamente non è più sincronizzato. EPG stesso contiene database, sistema operativo e servizi web nella Hardened Virtual Appliance (Kiteworks: Migration FAQ).

Un perimetro di migrazione completo comprende almeno:

• domini, route, identità relay e connettori nonché policy TLS;
• regole attive, priorità, trigger, eccezioni e percorsi di errore;
• chiavi S/MIME, OpenPGP, di dominio, TLS e CA, inclusa la cronologia;
• account WebMail, messaggi del portale, conservazione, template e nome pubblico;
• integrazioni con directory, SSO, SIEM, Syslog, DLP, archivio e applicazioni;
• ruoli, amministratori e accessi di audit e supporto;
• metrica di licenza, parco utenti attivo e limiti contrattuali;
• backup, ripristino, HA, DNS, monitoraggio e runbook.

Il test di accettazione deve verificare dati storici oltre ai nuovi messaggi. Per ogni vecchio tipo di crittografia viene aperto o decrittografato un messaggio creato prima della migrazione. Per ogni direzione viene inviata una nuova e-mail di test con e senza chiave destinatario disponibile. Vengono inoltre verificati casi negativi quali certificato non valido, hop successivo non raggiungibile e directory non disponibile. Solo in seguito il vecchio gateway può essere rimosso da DNS, connettori, allowlist e monitoraggio.

Alta disponibilità con backup e ripristino

Le FAQ di migrazione EPG indicano clustering integrato, backup/ripristino, disaster recovery, alta disponibilità e distribuzione come caratteristiche della Hardened Virtual Appliance. Tuttavia, non affermano che ogni singola funzione EPG riceva automaticamente lo stesso RPO e RTO. Coda di posta, database, chiavi, contenuto del portale, audit log, configurazione e archiviazione esterna di oggetti o file devono essere assegnati separatamente secondo l’architettura (Kiteworks: Migration FAQ – Hardened Virtual Appliance).

Con Totemomail legacy, la procedura di backup dipende da versione e installazione. L’affermazione EPG sul backup integrato non deve essere applicata retroattivamente a un vecchio database esterno o a un archivio WebMail separato. Il percorso di supporto del produttore, la documentazione installata e un test di ripristino isolato sono qui le fonti primarie.

Monitoraggio e gestione della sicurezza

Kiteworks conferma per EPG l’esportazione verso una o più destinazioni Syslog nonché l’integrazione Splunk. La documentazione della piattaforma descrive log e metadati normalizzati relativi alle e-mail e ad altri canali di comunicazione. Per gli amministratori di messaggistica rimane decisiva la correlazione funzionale: audit della piattaforma, evento SMTP, decisione della policy, operazione sulla chiave, accesso al portale e Message Trace a valle devono essere riuniti tramite tempo, identità e identificatore del messaggio (Kiteworks: Migration FAQ – syslog, Kiteworks: EPG logging and audit).

Un dashboard amministrativo dovrebbe visualizzare almeno accettazioni e rifiuti, età della coda per hop successivo, errori di policy, numero e tipo di azioni crittografiche, chiavi mancanti o non valide, scadenza dei certificati, latenza LDAP, errori di login al portale, stato del disco e del database, replica del cluster, età del backup e perdita Syslog. Una coda vuota è un riscontro positivo solo se contemporaneamente i messaggi vengono accettati e consegnati con successo all’hop successivo.

Syslog via UDP non offre consegna garantita. Per dati di audit da proteggere vanno pianificati trasporto TLS, buffering, autenticazione della destinazione, orario corretto e un allarme di guasto (RFC 5424, RFC 5425). I log possono contenere mittenti, destinatari, oggetti, informazioni sui certificati o attività del portale; minimizzazione dei dati e protezione dell’accesso fanno pertanto parte della policy di logging.

Le segnalazioni storiche di sicurezza mostrano che anche l’interfaccia web fa parte della superficie d’attacco. Le voci NVD documentano, tra l’altro, precedenti vulnerabilità CSRF, di accesso a oggetti e XSS nei componenti web Totemomail. Da ciò non deriva alcuna affermazione su uno stato di patch arbitrario e non verificato, ma resta l’obbligo permanente di includere avvisi del produttore, esposizione, stato di supporto e test del portale web nella gestione delle patch (NVD: CVE-2018-6563, NVD: CVE-2020-7918, NVD: CVE-2024-28063).

La diagnosi segue un messaggio di test dall’accettazione, passando per la decisione di policy e chiave, fino all’uscita SMTP o all’accesso al portale.

Strumenti di diagnosi

La diagnosi inizia dal percorso di posta pubblicato e segue poi gli eventi EPG fino al recapito o a WebMail. La migrazione della piattaforma e lo stato della licenza vengono verificati solo quando è stato identificato il passo di elaborazione interessato.

DNS e percorsi di posta pubblici

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 e dig mostrano l’MX pubblico, l’indirizzo del gateway ed eventualmente DANE-TLSA. La vista del resolver interno ed esterno deve essere verificata separatamente. Con Microsoft 365, l’MX descrive solo il primo hop Internet; connettori e regole di trasporto determinano l’ulteriore percorso.

Raggiungibilità TCP, SMTP e TLS

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 e nc dimostrano solo il percorso TCP. curl.exe di Windows richiede SMTP-STARTTLS; openssl s_client mostra capacità, handshake, SNI e catena di certificati. Solo una transazione SMTP completa con risposta DATA positiva dimostra l’accettazione.

Messaggio di test SMTP autorizzato

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 e swaks inviano qui un messaggio di test controllato. Mittente, destinatario e destinazione devono essere espressamente autorizzati a tale scopo. Devono essere registrati risposta SMTP finale, ID gateway, policy attivata, chiave utilizzata o percorso del portale, hop successivo e arrivo effettivo. Un 250 su RCPT TO non costituisce ancora accettazione del contenuto del messaggio.

Percorso WebMail o portale

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 e openssl s_client verificano l’interfaccia HTTP e TLS. Un codice di stato riuscito non dimostra né il login né l’accesso alle chiavi. Un test sintetico del browser deve coprire accesso, apertura di un messaggio noto, allegato e risposta.

Percorso dei pacchetti nel punto di misurazione corretto

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 e tcpdump vedono il traffico soltanto nel punto di misurazione selezionato. Un client amministrativo non osserva automaticamente il percorso tra Exchange Online, Load Balancer ed EPG. Per l’analisi sono adatti un host autorizzato, Port Mirror o Cloud Flow Logs; SMTP prima di STARTTLS e i metadati web devono essere conservati con adeguata protezione.

Storia tecnica

Totemo è stata fondata in Svizzera nel 2001 e ha sviluppato soluzioni per crittografia e-mail, Managed File Transfer e comunicazione mobile. Le convalide NIST del 2012 e del 2019 documentano lo sviluppo del Totemo Cryptographic Module basato su Java e della Totemo Security Platform su sistemi operativi appliance proprietari (Entrust Partner Directory: Totemo, NIST: TCM Security Policy 2012, NIST CMVP Certificate 3500).

Kiteworks ha acquisito totemo nel gennaio 2022. La documentazione del produttore descrive l’integrazione del codice Totemomail nella piattaforma Kiteworks e la ridenominazione in Email Protection Gateway. EPG ha combinato le funzioni esistenti di crittografia e-mail con la Hardened Virtual Appliance, ruoli condivisi, log normalizzati e altri canali di comunicazione Kiteworks (Kiteworks: acquisition and EPG integration, Kiteworks: Migration FAQ, Kiteworks: January 2022 acquisition).

La transizione è tecnicamente rilevante: il vecchio prodotto poteva funzionare con un database esterno; EPG acquisisce i relativi dati in un database integrato e sposta la manutenzione del sistema operativo e del database entro il confine dell’appliance. Runbook, monitoraggio e ripristino non devono quindi limitarsi a sostituire termini di prodotto, ma devono riassegnare superfici di controllo, dati memorizzati e configurazioni.

Fonti

• 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 – Comunicazione e-mail sicura con 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 – pagina man di dig
• Microsoft Learn – Test-NetConnection
• OpenBSD – pagina man di nc
• curl – pagina man della riga di comando
• OpenSSL – s_client
• swaks – strumento di test SMTP
• Microsoft Learn – Invoke-WebRequest
• Microsoft Learn – pktmon
• tcpdump – pagina del manuale
• Entrust Partner Directory – Totemo
• NIST – Totemo Cryptographic Module Security Policy 2012
• Kiteworks – The Deal: On the Hunt